1. Field of the Invention
The present invention generally relates to data processing. More particularly, embodiments are provided for program timers.
2. Description of the Related Art
Inherent in any software development technique is the potential for introducing “bugs”. A bug will typically cause unexpected results during the execution of the program. Locating, analyzing, and correcting bugs in a computer program is a process known as “debugging.” Debugging of programs may be done either manually or interactively by a debugging system mediated by a computer system. Manual debugging of a program requires a programmer to manually trace the logic flow of the program and the contents of memory elements, e.g., registers and variables. In the interactive debugging of programs, the program is executed under the control of a monitor program (known as a “debugger”). The debugger may be located on and executed by the same computer system on which the program is executed or may be located on a different system from the one the program is executed on, in the case of a distributed debugger.
Conventional debuggers typically support various operations to assist a computer programmer. Each operation allows the programmer to examine the state of program registers and variables at a given point in the execution of a program. A first operation supported by conventional debuggers is a breakpoint operation. A “breakpoint” is a point in the program where execution of the computer program is stopped so that the state of the program can be examined by a computer programmer. As a result, when a computer program is executed by a debugger, the program executes in a normal fashion until a breakpoint is reached. The debugger then stops execution and displays the results of the computer program to the programmer for analysis.
In some cases, the use of breakpoints (and other debugging tools which cause program stoppage) can result in problems with internal program timers, which are used to ensure proper operation and execution of the program. Such internal program timers are incremented according to a system clock. The system clock is itself updated by hardware and, as a result, continues to increment even while any individual process is halted (e.g., for debugging upon encountering a breakpoint).
The operation and associated problems of such a timing scheme may be illustrated with reference to FIG. 1. FIG. 1 shows an execution environment for illustrative system 100. The system 100 is executing a process 102 which includes a first function 104 and a second function 106. The functions 104, 106 may be executed within a common thread. The timing of the functions 104, 106 is checked by implementing an operating system timer 108 (referred to herein as the system timer) which is configured with a cache area 110 to store a start time. A hardware-based system clock 112 is utilized to increment the system timer 108 according to predefined units of time.
In operation, the first function 104 begins executing at step 120. At step 122, the first function 104 initiates the system timer 108 and stores the start time into the cache area 110. The system 100 is then configured to periodically query, at step 136, whether the system timer 108 has expired. If the system timer 108 has expired, the associated thread is then ended at step 138. Otherwise, processing proceeds to step 140 where no action is taken and the system timer 108 continues to increment.
The determination at step 136 is made using an expected timer wait value (or allowed run time), which may be user configurable. The expected timer wait value is the maximum time needed for the process 102 to complete execution assuming no errors are encountered. The expected timer wait value is then compared to an elapsed run time, which is the difference between the current system time (as defined by the system clock 112) and the start time contained in the cache area 110.
Once the system timer 108 is initiated, a call is made, at step 124, to the second function 106, which is entered at step 126. Illustratively, the second function 106 is configured with a breakpoint (which may have been set by a user at some earlier time) encountered at step 128. Accordingly, the process 102 and its related threads are halted upon encountering the breakpoint at step 128. The user is then free to inspect variables and engage in other debugging activities. Subsequently, the user inputs a command to the system causing the process 102 to resume execution. Assuming that the system timer 108 has not expired, execution of the second function 106 proceeds to step 130 from which processing returns to the first function 104. As indicated by step 132 of the first function 104, execution continues until step 134 where the system timer 108 is stopped.
If, however, the system timer 108 has expired when execution of the process 102 resumes, an error path code will be entered. This situation arises because the system timer 108 continues to be incremented even though the process 102 and its threads have been halted as a result of encountering the breakpoint at step 128. As a result, the calculated elapsed run time is erroneously inflated and is not indicative of the actual elapsed run time.
One solution to the foregoing problem is to change the timer values to account for possible program stoppage due to breakpoints. However, the solution is undesirable because the utility of the timer as an error indicator is undermined. In addition, it is necessary to recompile the program following a change to the timer values, thereby increasing the overhead associated with debugging.
Therefore, a need exists for timers adapted for use in environments where execution is periodically halted and restarted.